なぜScrapboxにはstaff featureフラグが無いのか
全ての新機能はNota社員と全scrapboxユーザーに同時に配信される
staff featureがあるとリリース力が落ちると思っているshokai.icon 新しい機能を実装する時に最も力が必要な瞬間は2つ
作り始め
あとはemacsとdockerをすぐ起動できるMacがあれば、乗り越えれる
作り切る
クオリティを80点ぐらいから仕上げるのが大変
細かい挙動・見た目・例外処理の調整など
shokai.iconは、作り切るフェーズを乗り越えるために飢餓感を利用している この素晴らしい機能が目の前にあり、今すぐ俺は使いたい
どう良いものなのかをpull requestの概要文などに厚く記述する
だから絶対に完成させるのだという意思を高める
staff featureを付けると
クオリティ80点でstaff向けにリリースできてしまい、自分はstaffなので使えてしまう
飢餓感がなくなり、満足し、永遠にリリースできなくなる
staff featureが増えると
一般ユーザーとstaffとでだんだん別のアプリケーションを使っている状態になっていく
ユーザーの気持ちをシミュレートできなくなる
if文だらけでbugの原因になる
メンテナンス不能になっていく
昔のパッケージソフトでよくあった、顧客毎の細かいカスタマイズ・カスタムビルドだらけと同じ状態
オンプレ版は顧客にscrapboxがどういう機能を持っているかを説明しなければならない
目に見えない隠された機能（コード）があればあるほどセキュリティリスクは上がる
実はwebサービスは100点でなくてもいい
bug報告してくる人にお礼言って素早く直すと、なぜか感心されてファンになってくれてお得 さすがにユーザーのデータが壊れるとか、情報漏洩とかは困るので、そういうところはきっちりやる
一方、ちょっと挙動がおかしい程度の問題を高速に直すのはマジで楽しい
リリース前だと、ちょっと挙動がおかしいのを直すのは苦痛である
とにかくめんどくさく感じる
リリース後にやるとなぜか楽しい。なんでだろ？shokai.icon
昔scrapboxにもstaff featureを導入しようとした事があった
staff featureに担わせるべきではない事を列挙している
便利かどうか、コンセプトの確認
ぱっと見て良いとわからない、あるいはコンセプトをpull requsetのテキストで説明できていない時点でダメ
クオリティが低いのでとりあえずstaff向けリリース
ここを乗り越えれば自分の能力が上がって後で得するので気合いでやる
特に、個別のstaff feature毎にオンオフできる機構は、品質が上がらない構造を産む
機能Aを有効にしてるけどBは有効にしてないスタッフ1
機能Bを有効にしてるけどAは有効にしてないスタッフ2
機能AとBを併用した時のbugに気づけるのは、両方とも有効化しているスタッフだけ
それほど機能間の連動性が重要ではないとしたら、機能毎に個別ツールにとしてネイティブアプリで提供すればいい
品質・完成度・コンセプトに自信が無いから社内向けにチョイ出しする、というstaff限定フラグ自身が、品質向上の妨げになる